Default to bitrouter/auto, and read the catalog off the real wire - #6

What

1. bitrouter/auto leads every catalog, and is the default model. The request carries bitrouter/auto as its model and BitRouter's routing policy picks per request. The config hook names it as both model and small_model, so a fresh opencode.json carrying nothing but "plugin": ["@bitrouter/opencode"] is a complete installation.

??= is the whole of the courtesy: a model the user wrote themselves, or another plugin set first, is left exactly as it stands. Routing the small-model errands through auto is what the auto route is for — BitRouter's own ladder is a better judge of "cheap enough for this" than a hardcoded second model id.

bitrouter/auto is the default, not the only option — the rest of the catalog is registered behind it.

Before authentication on cloud the provider is now seeded with the auto route alone rather than a kimi-k2.5 placeholder; without at least one model the provider would not be selectable and /connect would be unreachable.

2. The discovery field mapping was wrong against both data planes.

Neither plane sends context_window, a flat cost object, or boolean reasoning/tool_call fields — which is what this plugin was reading:

Verified against the live endpoints: all 50 cloud models now carry true context windows (1M for Fable 5, 200K for Opus 4.6, Haiku's 8192 output cap) where previously every one fell back to the default.

Absent capability tokens read as "the plane did not say" rather than "no" — the local daemon never sends them, and a coding agent is unusable against a model it believes cannot call tools.

test/wire.test.ts pins the mapping against bodies captured verbatim from both planes, so a field rename upstream fails a test rather than silently defaulting a model.

Placeholder capacities

Until BitRouter's catalog lists auto, the entry is synthesized at 128K context / 16K output. Those are deliberately the floor rather than the ceiling: auto may land on any model in the ladder, and the two wrong answers do not cost the same — under-claiming compacts a session early, over-claiming fails a request outright, mid-turn. A served auto entry always wins, so real capacities arrive with no release here.

Verified end to end ✅

Against a live BitRouter daemon carrying the reserved-namespace build, with an auto preset bound to a routing policy:

The model id is bitrouter/auto ⚠️ (corrected)

An earlier revision of this branch used a bare auto. That was wrong: BitRouter reserves the whole bitrouter/ namespace for itself (RESERVED_NAMESPACE) and bitrouter/auto is the public slug (AUTO_SLUG) — the vendor segment names the router being addressed, not the token destination. A bare auto gets 404 no active provider declares model 'auto'.

Two consequences, both now reflected in the code and docs:

• GET /v1/models will never list this id. The namespace resolves before any provider lookup, and the registry validator refuses catalog models under bitrouter/ — so the entry has to be synthesized here. The "once the catalog lists it" framing in the first revision was wrong.
• It needs a preset named auto bound to a routing policy. Without one the gateway answers 400 naming bitrouter optimize setup. Worth knowing before this ships to users, since a fresh install has no such preset.

The reserved-namespace support is not in the released binary — homebrew 1.0.0-alpha.26 returns 404 for it; alpha.27 dev builds resolve it. That, not this branch, is the real release gate.

Tests

45 → 63, including the new wire.test.ts fixtures.

🤖 Generated with Claude Code